InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/misc/merit/noop/plans/barns

Internet Message Format | 1991-07-30 | 27KB

From [e-mail] Mon Jul 29 19:10:44 1991
Received: Mon, 29 Jul 91 19:10:40 EDT by rivendell.merit.edu (5.51/1.6)
Received: by merit.edu (5.65/1123-1.0)
    id AA02484; Mon, 29 Jul 91 19:08:07 -0400
Received: from gateway.mitre.org by merit.edu (5.65/1123-1.0)
    id AA02480; Mon, 29 Jul 91 19:08:00 -0400
Return-Path: <[e-mail]>
Received: by gateway.mitre.org (5.61/SMI-2.2)
    id AA12816; Mon, 29 Jul 91 19:07:26 -0400
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Document by Barns, "OSI Network Addresses for the DOD Internet"
Date: Mon, 29 Jul 91 19:07:21 -0400
From: [e-mail]
Status: RO


          OSI Network Addresses for the DoD Internet

              Draft Version 4 - 23 January 1991





                          SECTION 1

                  BACKGROUND AND ASSUMPTIONS


The U.S. Government has made a policy decision that the Open
Systems Interconnection (OSI) communication protocols should
be used for interoperable communications between Government
computer systems.  The Department of Defense (DoD) has
established a requirement that new systems and major system
upgrades should employ the OSI protocols specified in the
Government Open Systems Interconnection Profile (GOSIP) as the
sole mandatory interoperable protocol suite in DoD.  These
policies are documented in Federal Information Processing
Standard (FIPS) Publication 146 and in a memorandum from the
Assistant Secretary of Defense (Command, Control,
Communications, and Intelligence) dated 2 July 1987.  The
implementation of these policies creates a requirement for
various communication networks in DoD to provide the
infrastructure needed to support systems using OSI protocols.

The use of OSI communication protocols requires that
communicating systems be assigned OSI network addresses.  This
document describes how these addresses are assigned and used
in the DoD Internet.


1.1  SCOPE

This document defines the structure, assignment procedures,
and management procedures for OSI Network Addresses to be used
in unclassified, fixed-plant segments of the DoD Internet.  It
also provides advice to network operators in determining those
aspects of their local OSI addressing plans which they have
authority to decide.

This scheme may also be applied to classified or mobile DoD
networks when analysis shows it to be operationally
satisfactory.


1.2  TERMINOLOGY

OSI defines two types of address-like identifiers in the
Network Layer, Network Service Access Point (NSAP) addresses
and Network Entity Titles (NETs).  The distinction between the
two is primarily that an NSAP is the address of an endpoint of
network layer communication, while an NET identifies an
intermediate system in a network layer communication.  The
same address structure is used for both NSAPs and NETs, so the
term NSAP is used throughout this document and should be
understood to implicitly include NETs.

The OSI routing framework uses the notions of Administrative
Domain and Routing Domain to define the scope within which
routing-related actions occur.  Since addressing is closely
related to routing, the organization of portions of the global
network into administrative domains and routing domains
affects the assignment of NSAPs to OSI systems.  An
administrative domain is a portion of the global OSI network
that is provides the OSI network service under the control of
a single administrative entity.  An administrative domain
contains one or more routing domains, each of which provides
routing service for some set of traffic flows within the
administrative domain.  The engineering aspects of an OSI
network are mainly concerned with routing domains rather than
administrative domains.

OSI uses the term subnetwork to identify a particular
interconnection facility used by network layer entities to
communicate with other network layer entities.  Examples of
subnetworks include X.25 networks such as the MILNET backbone,
LAN networks such as Ethernets, and private leased lines
between systems.  Subnetworks fall into three general
categories: broadcast subnetworks, such as Ethernets; general
topology networks, such as X.25 networks; and point-to-point
subnetworks, which are dedicated links.  Subnetworks do not
have any specific relationship to the OSI routing
architecture.  A subnetwork might carry traffic between
systems in the same or different routing domains.  The systems
connected to subnetworks are the members of routing domains,
and the relationship between subnetworks and routing domains
at any given time is a result of the routing domain
affiliation of the connected systems and of the routing
decisions made in those routing domains.


1.3  ASSUMPTIONS

The scheme presented here is intended to be consistent with
the following assumptions:

  +   The scheme should be consistent with GOSIP 2.0 unless
      there are very strong reasons for deviation.

  +   The scheme should be compatible with the expected
      characteristics of contractor off-the-shelf (COTS)
      products.

  +   The scheme should assume that future versions of GOSIP
      will incorporate features and mechanisms now being
      developed in international standards bodies, and that
      DoD will use these features.

  +   The scheme should be compatible with Draft International
      Standard (DIS) 10589 Intra-Domain Intermediate System to
      Intermediate System (IS-IS) routing protocol, as this is
      expected to be specified in a future version of GOSIP.

  +   The scheme should support either centralized or
      decentralized administration of address assignment.

  +   The scheme should allow substantial autonomy in local
      network routing arrangements for subscribers desiring
      it.

  +   The scheme should consider the impacts of address
      assignment on the efficiency of packet routing in the
      DoD Internet.  Specifically, it is desirable to minimize
      total path length, avoid repeated transits of the
      backbone, and minimize the volume of routing protocol
      traffic required in the DoD Internet.

  +   The scheme should be capable of working effectively in a
      DoD Internet containing many more systems than the
      present DDN.

  +   The scheme should be compatible with an environment
      containing one or many long-haul backbones.


1.4  CLARIFICATION OF INTERNATIONAL CODE DESIGNATOR (ICD)
       USAGE

The usage of ICD 5 and ICD 6 implicit in this document is
based on recent determinations by DOD, in consultation with
NIST, which differ from the view stated or implied in some
older documents.  GOSIP Version 2 allows the use of ICD 5 by
all Government agencies, including DOD.  ICD 5 is administered
by GSA on behalf of NIST.  ICD 6 has been assigned directly to
DOD.  The purpose of the ICD 6 assignment is to provide an
administrative framework for DOD action independent of
ordinary GOSIP usage.  It is currently intended that ICD 6
only be used in cases where a technical difference (as well as
an administrative distinction) is involved.  The only such
usage at this time is in the construction of object
identifiers for TCP/IP managed objects.







                          SECTION 2

            ASSIGNMENT OF GOSIP NSAP FIELD VALUES


NSAPs required for MILNET devices and for systems accessing
MILNET via DOD-operated networks or gateways will be assigned
in accordance with a single numbering plan, defined below.
This plan employs the standard GOSIP NSAP format.

It is understood that the requirements for NSAP assignment in
some special environments (such as highly mobile systems) have
not been fully analyzed yet.  It is intended that the NSAP
format and assignment strategy defined here should be used in
those environments if it meets the operational requirements,
but other formats or assignment strategies may be adopted if
this approach is found to be inadequate.


2.1  USE OF GOSIP NSAP FORMAT

NSAP Addresses assigned under this plan are constructed
according to the format to be specified by FIPS 146-1, GOSIP
Version 2.0, when issued.  The encoding and usage of these
NSAPs in network traffic will comply with any applicable
standards cited in GOSIP Version 2.0.


2.2  OVERVIEW OF NSAP FIELD VALUES

For DoD use, the values in the fields of the GOSIP V2 NSAP are
assigned as follows:

  AFI (Authority and Format Identifier):
      This will be AFI value 47, encoded as two BCD digits.

  IDI (Initial Domain Identifier):
      This will be IDI value 0005, encoded as four BCD digits,
      designating International Code Designator (ICD) 5.

  DFI (DSP Format Identifier):
      This will be value 128 decimal, encoded as a 1-octet
      binary integer, as specified by GOSIP.

  AAI (Administrative Authority Identifier):
      DCA, on behalf of DOD, will obtain a registered AAI
      value from the Address Registration Authority for ICD 5,
      for use with this numbering plan.  This single value
      will be used in all NSAPs constructed under this
      numbering plan.  For convenience, this value is referred
      to as the MILNET AAI.  Other AAIs may be used in the
      future as requirements are defined for them.  It is
      expected that one or more additional AAIs will be
      assigned for DISNET segments.  AAI values are encoded as
      3-octet binary integers.

  RESERVED:
      This 2-octet field will be set to zero.

  RD (Routing Domain):
      RD numbers will be assigned by the Address Registration
      Authority to be established by DCSO.  RD numbers may be
      assigned either to subscriber domains or to DCA-
      controlled domains as appropriate to the specific
      requirements being supported.  The DCSO Address
      Registration Authority will record all assignments of RD
      numbers under the MILNET AAI.  RD numbers are encoded in
      the NSAP as 2-octet binary integers.

  AREA:
      AREA number assignments may be made by the
      administrative authority of a particular Routing Domain
      as necessary to meet their operational requirements.
      AREA numbers are encoded in the NSAP as 2-octet binary
      integers.  The DCSO Address Registration Authority will
      assign area numbers within DCA-controlled routing
      domains as required.

  ID (System Identification):
      ID numbers will be determined in accordance with
      procedures of the Routing Domain to which the NSAP
      belongs.  ID numbers may be 48-bit MAC addresses, where
      feasible, or other unique identifiers assigned by the
      administrator of the Routing Domain.  THe ID number is
      encoded in the NSAP as a 6-octet binary integer.  The
      DIS 10589 routing protocol forbids duplicated ID values
      within an area, and also requires that each ``level 2
      IS'' in a routing domain have a distinct ID value.  It
      is recommended for simplicity's sake that each routing
      domain require that all IDs in that routing domain be
      unique.

  NSEL (N-Selector):
      NSEL values may be selected by the end system or
      intermediate system to which the ID belongs, in
      compliance with the standards established by GOSIP.
      NSEL is encoded as a single octet.







                          SECTION 3

 DCSO REGISTRATION AUTHORITY PROCEDURES AND RESPONSIBILITIES



3.1  REGISTRATION AUTHORITY FOR MILNET AAI

DCSO is responsible for establishing a Registration Authority
for NSAP address assignments under the MILNET AAI.  The DCSO
Registration Authority has the following specific
responsibilities:

  +   The DCSO RA shall obtain an AAI assignment for the
      MILNET AAI from the Registration Authority for ICD 5.
      This assignment shall be recorded and managed in
      accordance with requirements specified in the GOSIP FIPS
      and the GOSIP User's Guide.

  +   The DCSO RA shall accept applications from organizations
      authorized to use DoD communication systems for
      assignment of Routing Domain (RD) numbers valid within
      the scope of the MILNET AAI.  The DCSO RA will review
      requests for technical validity and compliance with
      administrative requirements, and will furnish the
      requesting organization with the RD number assigned or
      with the reasons for not assigning an RD number.

  +   The DCSO RA shall accept applications from organizations
      authorized to use DoD communication systems for
      assignment of AREA numbers valid within the scope of
      DCSO-administered RDs.  The DCSO RA will review requests
      for technical validity and compliance with
      administrative requirements, and will furnish the
      requesting organization with the AREA number assigned or
      with the reasons for not assigning an AREA number.

  +   The DCSO RA shall maintain a permanent register of all
      NSAP field values assigned by the RA.  The register
      shall include the value assigned and full identification
      of the organization to which it has been assigned, the
      date of original assignment, and the date of each change
      to the registration information.

The DCSO RA has the following additional responsibilities:

  +   The DCSO RA shall obtain, record, and administratively
      manage additional AAIs for DoD activities as directed by
      competent authority.

  +   The DCSO RA shall act as the holder of record for ICD 6,
      which has been granted to DoD by the Registration
      Authority for International Code Designators, and shall
      act as Registration Authority for all uses of ICD 6
      requiring a Registration Authority.  The DCSO RA may
      delegate any of its registration responsibilities to
      subsidiary authorities.  Complete records of
      registration actions and delegations of registration
      responsibilities pertaining to ICD 6 shall be maintained
      by the DCSO RA.


3.2  USING ORGANIZATION REGISTRATION PROCEDURES

Using organizations are responsible for requesting assignment
of NSAP field values needed by their OSI systems.  Requests
should be directed to the appropriate Registration Authority
for the value being requested.

[Specific procedures TBD]







                          SECTION 4

           NSAP ASSIGNMENT GUIDELINES AND EXAMPLES


When an OSI system comes into existence in the MILNET
environment, the system must be registered with some
appropriate authority in order to obtain assigned values for
the RD, AREA, and ID fields of its NSAP.  This section
provides discussion and examples of how OSI networks and
systems can be organized into routing domains and areas, and
the administrative and operational effects of different
choices.

The first step in obtaining an NSAP for a system is always to
determine an appropriate RD for the system, since the
responsibility for further assignment depends on which RD is
involved.  The system can either be incorporated in an
existing RD, or a new RD (with a newly assigned RD value) may
be created.  The choice should be based on the following
guidelines.


4.1  CHARACTERISTICS OF A ROUTING DOMAIN

A Routing Domain is formally defined as a set of ISs and ESs
that employ a common routing procedure.  An RD will usually be
a compound entity, consisting of many hosts, and perhaps
making use of many subnetworks.  RDs usually contain one or
more Intermediate Systems (routers).  RDs will interface to
other RDs through a small number of interconnections, but they
may have a complex internal structure.  RDs typically have the
following characteristics:

  +   All intermediate systems at the perimeter of an RD will
      usually be managed by a single authority.

  +   RDs should be internally connected (that is, each system
      in the RD should be able to reach every other system in
      that RD without going through some intermediate system
      outside of that RD).

  +   All ISs within an RD must perform routing in a
      consistent manner.  This usually means that they use the
      same interior routing protocol and that any static
      routes are configured consistently throughout the RD.

  +   The internal structure of RDs is usually invisible from
      the point of view of another RD.  When traffic needs to
      flow from one RD to another, it takes the shortest path
      to the destination RD regardless of whether the path
      within the destination RD from that interconnection
      point to the destination system is short or long.
      Therefore, it is usually desirable to arrange RD
      boundaries so that the ``cost'' of connections within an
      RD is relatively insensitive to the particular path
      chosen.

  +   Policy on routing of traffic exiting the routing domain
      currently needs to be uniform throughout a routing
      domain.  This does not mean that every system in a
      routing domain must have identical rights to communicate
      with the outside.  It does mean that for those cases in
      which communication is allowed, there is no way to make
      the choice of external path depend on which system in
      the RD originated the traffic.  Policy-based routing
      protocols, which would alleviate this restriction, are
      still a research topic.

The GOSIP address structure allots two octets for RD
identification within an AAI.  This allows up to 65,536
routing domains per AAI.  It is expected that the actual
number of RDs assigned under the MILNET AAI will be smaller,
on the order of 500 to 5000 over the next several years.
These routing domains are logical peers of each other, even
though they may have only indirect connectivity via some other
RD.


4.2  ROUTING CONSIDERATIONS IN AAI AND RD ALLOCATION

In order to reduce the volume of routing information that each
RD must know about, it is desirable to use AAI numbers in
conjunction with RDs in such a way that useful routing
decisions can be made on the basis of the AFI, IDI, DFI, and
AAI fields.  This implies that the AAI has some topological
meaning, even though the name suggests otherwise.

The concept of the MILNET AAI (and of the implicit future AAIs
for DISNET or other large, topologically distinct regions of
the DOD Internet) is introduced to reduce the volume of
routing information needed to interconnect with other parts of
the DOD or external Internets.  Routing domains outside of the
DDN will not need separate routing information for all of the
different RDs associated with MILNET users.  Conversely,
systems in the RDs assigned under the MILNET AAI will not need
separate routing information for each non-DOD RD with which
they need to communicate.  In both cases, the presence or
absence of the MILNET AAI (and higher-order fields of the
NSAP) identifies traffic that should be routed to the DDN ISs
that support external connectivity (analogous to the current
Mailbridges).

Within the RDs associated with one AAI, a hierarchy of routing
domains can be set up so that it will not be necessary for all
ISs on RD boundaries to have complete routing information for
the other RDs.  This technique seems mainly useful when static
inter-domain routing is used (which will be the initial
situation in GOSIP networks, since dynamic inter-domain
routing protocols have not yet been standardized).  Each level
of hierarchy introduces an extra hop in the path between two
RDs that don't have direct knowledge of each other, so it is
desirable to keep the hierarchy flat.  A two-level hierarchy
can be implemented without any special restrictions on RD
number assignment.


4.3  CHARACTERISTICS OF AN AREA

The AREA portion of the NSAP was provided to allow
hierarchical structuring within a routing domain.  Routing
protocols are being developed to use the concept of Areas in
specific ways.  ISO DIS 10589, in particular, treats areas as
distinctly addressable regions; routing domains using this
protocol can be set up so that some routers (Level 1 routers)
only know about the end systems in a single area, while other
routers (Level 2 routers) keep track of the topology of
interconnections between areas.  This makes it possible to add
or remove end systems without having to send routing
information updates outside of the particular area affected.

The choice of area boundaries should consider logical
administrative divisions, reasonableness of the Level 2
topology generated, and reasonable sizes for the areas.  The
following guidelines are offered for defining areas that are
operationally efficient:

  +   Small routing domains should use a single AREA value.
      There is no specific limit on the size of a small RD,
      but a maximum of 5 to 10 routers and 50 to 100 end
      systems is suggested as a guideline.

  +   Areas must be fully connected (every system in an area
      should be able to reach every other system in that area
      without having to go through an IS that is not in that
      area).

  +   All end systems that are connected to a single broadcast
      subnetwork are normally organized as a single area or as
      a part of a single area that includes other subnetworks.

  +   In a large routing domain, the ideal number of areas (in
      terms of maximizing routing efficiency) is approximately
      the square root of the total number of end systems and
      intermediate systems in the routing domain.  However, it
      is suggested that having a smaller number of areas is
      better than having extremely small areas.

  +   It may be useful to make separate areas for portions of
      a routing domain that are known to be unstable (systems
      or subnetworks going up and down frequently, frequent
      changes to configuration, etc.) to isolate the rest of
      the routing domain from having to process all of the
      routing updates generated by those systems.


4.4  EXAMPLES OF NSAP ASSIGNMENT FOR DIFFERENT CONFIGURATIONS

4.4.1  Concentrator Installation as a Routing Domain

One widely employed network configuration uses a
``concentrator'' (an OSI Intermediate System and one or more
associated local subnetworks) to connect many devices at a
base, post, camp, or station to the MILNET.  There are two
possible ways of arranging the addressing for such a
configuration: as an area or as a routing domain.

It will probably be most common to have a distinct RD assigned
for each such base concentrator and the devices it serves.
The administrator of each such Routing Domain assigns AREA and
ID values to the systems that access the DDN through the
concentrator.

If a base network is connected to the DDN through more than
one IS, it is still possible and often appropriate to organize
the entire complex as a single routing domain with one RD
number.  This assumes that the complex as a whole meets the
technical constraints on a routing domain as described
previously.

There may be smaller portions of a base network which should
become separate Routing Domains to accommodate a special
requirement, such as rapid redeployability of an
organization's network at another location or a need to use a
routing strategy incompatible with the rest of the base
network.  These situations will need to be analyzed on a
case-by-case basis.  Section 4.4.4 below discusses deployable
organizational networks.

4.4.2  Concentrator Installation as an Area of a DDN Routing
       Domain

DCSO may establish a service in which using organizations may
attach one or more subnetworks to a DDN-operated Routing
Domain using a subscriber-controlled Intermediate System (IS).
If this service is established, organizations subscribing to
the service must request that DCSO assign an AREA number
within the DDN-operated RD.  In this situation, registration
of ID numbers for end systems within the AREA will be the
responsibility of the organization to which the AREA number is
assigned.  The ID numbers for ISs must either be derived from
a global registry (such as globally unique MAC addresses) or
will be assigned by DCSO, in order to ensure uniqueness
throughout the RD.

4.4.3  End Systems Directly Connected to a DDN Subnetwork

An end system connected directly to the MILNET could either be
attached to some existing Routing Domain, if this is desired,
or may be assigned to a DDN-controlled Routing Domain
otherwise.  In either case, traffic destined for such an ES
will always transit an IS in the destination ES's routing
domain unless the traffic source is another ES on the same
subnetwork.  As a result, traffic coming from other RDs will
usually take one extra hop.  Since the router in the
destination's RD will be charged for this extra hop, most
subscribers will probably prefer to affiliate with a DDN-
controlled routing domain.

If an ES subscriber on a DDN backbone segment does not become
part of a subscriber-operated Routing Domain, DCSO will assign
RD, AREA, and ID values for the subscriber system.  It is


                              1
currently expected that a single RD value and a single AREA
value will be used for all such assignments for hosts
connected directly to MILNET, but this may evolve to meet
requirements as they are identified.

If a subscriber wants to put an ES into an existing










subscriber-operated Routing Domain, the subscriber needs to
contact the Registration Authority for that RD to acquire AREA
and ID assignments.  In this configuration, the ES must be
configured with the NSAP of at least one IS in the routing
domain, which serves as a source of routing information.

4.4.4  Deployable Networks

Some organizations have networks that are expected to be
deployable with the unit they support.  After a deployment
occurs, connectivity to the DDN would be reestablished using
whatever connection facilities are available at the deployed
location.

To support this application, the set of equipment which would
be deployed together should be organized as a separate routing
domain.  Routing arrangements would be set up at the current
location (regular or deployed) to connect this RD to some RD
readily accessible at that location.

The rationale for using a separate RD is to avoid having to
change addresses as part of a deployment action.  If the
deployed systems were part of a RD located elsewhere, it would
often be difficult to keep the RD internally connected (which
is necessary for routing to work correctly).  To take
advantage of subnetworks or RDs available at the deployed
location, the deployed systems have to either become part of a
RD there, or become a peer RD.  Setting up such a collection
of systems as a distinct RD even when not deployed will
minimize the effort needed to establish communications when a
deployment occurs.